BA ABCs: “B” is for BPMN

Howard Podeswa — Sun, 12 Sep 2010 23:21:00 GMT

#2 in the series: “B” is for BPMN
This blog continues a series on BA tools, based on my book “The Business Analyst’s Handbook”. In each blog, I move through the alphabet, highlighting a BA tool that begins with the letter of the day. Today’s letter is “B” – for Business Process Modeling Notation (BPMN). BPMN is the name of a standard often used for modeling business processes. The diagram covered by the standard is called a Business Process Diagram (BPD).

Example:
Figure 1 is a BPMN BPD that describes the process for reserving a room in a private-members club. The process begins when a member requests a reservation for a specified date. A reservations agent determines the rate and then takes one or more of the followings actions:

If the request included a query about basic rooms, the reservations agent checks the availability of basic rooms.
If the request included a query about deluxe rooms, the reservations agent checks the availability of deluxe rooms.
The slash on the flow marked “Query basic rooms” is a default, indicating this flow is selected if none of the conditions are true.

Next, the member selects a room. When the member’s response is received by the reservations agent, one (and only one) of the following actions is taken:

If the member has cancelled, the reservations process is cancelled.
If the member has selected one of the available rooms, then the reservations agent guarantees the reservations and the process ends in success.

Figure 1 - BPD diagram example: Reserve a room in a private-members club

The controversy: Activity diagram or BPD?

Since activity diagrams (the subject of the previous BA ABCs blog) cover the same ground as BPMN BPDs, the question naturally arises, “Which diagram is ‘better’”? In fact, a controversy rages on this issue, with arguments made for and against each approach – so it’s worth exploring. One of the major advantages touted for the UML (the standard that governs activity diagrams) is that by providing a single standard across the lifecycle, translation errors are avoided. By this reasoning, it makes sense to use activity diagrams for both business process modeling and for modeling the logic of the software processes that automate them. On the other hand, the BPMN standard is often seen as the more natural candidate for the specific purpose of modeling business processes. In fact, the commonly accepted best practice is for BAs to use BPMN for this purpose (unless there is a compelling reason to use activity diagrams – such as the use of a UML tool across the project) and to use the UML for its other diagrams – primarily class diagrams. Let’s consider the arguments for and against each option to try to ferret out the truth.

Argument #1: Activity diagrams are technical whereas BPMN BPDs are business-y

Because the UML standard came out of the development world, its diagrams are thought to be code-oriented. But this is more an issue of perception than fact. In truth, the UML is a full-spectrum standard that supports both real-world and technical modeling. While it is certainly the case that there are features of activity diagrams that are technically oriented, the fact is that only a small subset of features should be used by the BA when communicating with business stakeholders – and this subset corresponds closely to commonly understood flowcharting symbols. (The same can also be said for BPMN.) I have a strong suspicion that the word ‘Business’ in the BPMN acronym has had as much impact as anything else in this perception of BPMN’s preferred status for business usage. But when you compare the aspects of the two alternatives that are actually used by the BA, feature by feature, there is in fact little difference between the two, as the next argument explains.

Argument #2: As a whole, BPMN diagrams are easier for business stakeholders to understand than activity diagrams

To get past the rhetoric, let’s compare the modeling elements most useful for BA purposes. Figures 2 and 3 show commonly used BPMN symbols along with their activity diagram counterparts. A quick glance indicates that it is hard to tell the two apart. When you look at these elements side by side you really have to wonder what all the fuss is about. There is one situation, in fact, that is expressed in a clearer manner (from a stakeholder’s perspective) in activity diagrams than on a BPMN BPD: parallel activities. Figure 4 compares the BPD and activity diagram symbols used to indicate two activities that may occur in parallel (meaning that they may occur in any order). I think most people would agree that the BPD symbol – a diamond with an enclosed ‘+’ sign, is much more cryptic than the straightforward parallel lines used for this purpose on activity diagrams.

Figure 2 - BPD flow objects (with UML equivalents)

Figure 3 - BPD connecting objects (with UML equivalents)

Figure 4 - BPD parallel fork (with UML equivalents)

Argument #3: BPMN includes special modeling elements that make it more suitable for business purposes than activity diagrams

Here I do believe there is some merit to the argument in favour of BPMN. One situation not well handled by activity diagrams is the Inclusive-OR. This is the logical construct used to model the common expression ‘and/or’ – as in: Do ‘A’ and/or ‘B’ and/or ‘C’ – depending on various conditions. Figure 5 illustrates the approaches used in the two standards. BPMN BPDs are clearly preferable to the mess of symbols required by activity diagrams. Another situation for which BPMN has a dedicated symbol relates to the handling of events. Figure 6 illustrates the difference between the two standards. BPMN relies on the placement of a circular event symbol to communicate to the reader the timing of a response to an event: an event symbol on an activity means that the event interrupts it whereas an event after an activity means that the activity first is completed and then the event is noted and responded to. Activity diagrams have a fairy simple alternative notation for this – but it may not be as readily obvious to the reader what is being conveyed.

Figure 5 - BPD inclusive gateway (with UML equivalent)

Figure 6 - BPD events (with UML equivalent)

Argument #4: BPMN models B2B interactions better than activity diagrams

In the ‘real world’, businesses interact with other businesses in limited ways, whereas organizational units within a single business have more complex interactions. In BPMN, this is modeled using pools and lanes. A business is represented as a pool and an organizational unit within the business is represented as a lane. Interactions between pools are limited to the passing of messages – effectively mirroring the way that businesses pass requests (messages) to each other while being unaware of each other’s internal processes. Figure 7 illustrates this approach. There is no formalism dedicated to this concept in activity diagrams, though the situation is fairly easily modeled by stipulating that businesses communicate by sending and receiving signals. Nevertheless, signals are not widely used for business process modeling and are less likely to be readily understood than pools by business stakeholders.

Figure 7 - BPMN B2B model using pools

Conclusion
For business process modeling, where all the players are within a single business, there is no compelling argument for either standard. While there are some small advantages to each standard, they tend to cancel each other out. (E.g., while BPMN handles the inclusive-or situation better, activity diagrams model parallel activities more clearly.) However, BPMN does have a clearer approach for modeling B2B interactions.

Final words
This discussion has focused entirely on the BA perspective. A separate set of arguments and comparisons could be made with respect to the suitability of the two alternatives for code generation. But that is a topic beyond the scope of this blog.

Howard Podeswa, author of Noble Inc.
For courses designed by the author in Business Process Modeling, click here: http://www.nobleinc.ca/BA005.html

Top 10 Tech Skills: Process Modeling tops the list

Barton George — Tue, 07 Apr 2009 12:32:00 GMT

Last week I came across an article on NetworkWorld.com that listed today’s “Top 10 Technology skills.” The list was based on work done by Foote Partners, which conducts quarterly assessments of IT pay trends in the US.

Foote Partners’ CEO David Foote says “what’s unique about this downturn is that IT departments are hiring talent in certain areas – such as business process modeling and project management – while laying off in others connected to weak product lines.”

And, indeed, coming in at the top of the list was Business Process Modeling:

1. Business Process Modeling

Business process management, methodology and modeling is one of the few IT niches that saw pay gains in the fourth quarter of 2008, according to the quarterly IT salary survey compiled by Foote Partners. In particular, companies were willing to pay for workers with ITIL IT best practices and CobiT IT governance experience. Pay for these skills was up 10.3% from a year ago and 5.6% from the previous quarter, the Foote report says.

Kevin Faughnan, director of IBM’s Academic Initiative, says business process modeling is one of the key skills that business majors should be studying. “It’s about how does our business work, what are the business processes and how do we analyze them,” Faughnan says, adding that this is a key issue for companies to consider before applying IT to solve business problems.

This seems to make sense to me. It is always important to know your business processes in order to be able to modify and refine them to keep pace with change… and today there is an extra helping of change that we all must not only keep pace with but get ahead of. Business Process Modeling is a key first step.

And the rest…

For the curious, the other 9 skills were:

2. Database
3. Messaging/Communications
4. IT Architecture
5. IT Security
6. Project Management
7. Data Mining
8. Web Development
9. IT Optimization
10. Networking

Barton George
Sr. Director, Business Development, Blueprint process mapping tool
Lombardi Software

Learn about Blueprint and sign up for a 30 day free trial

Morphis: Accidental Process Consultants

Barton George — Tue, 16 Dec 2008 23:28:00 GMT

Morphis is a company that provides currency supply chain management software and counts among its customers the U.S. Federal reserve as well as central banks, ATMs and armored car companies around the world. Process mapping was the furthest thing from their minds when they started in business but they quickly found out that if they didn’t start leading their customers in process mapping sessions they wouldn’t be able to sell their product.

Last week I chatted with Gary Faulkner of Morphis about how they found themselves unexpectedly leading process mapping sessions for customers or, as Gary likes to describe the turn of events, “A funny thing happened on the way to the software business.”

Take a listen:

>> My talk with Gary (6:59): Listen (mp3) Listen (ogg)

Process mapping enabled a pair-o-dime shift for this currency manager. (sources: my fingers and my dimes)

Some of the Topics we tackle:

Conundrum: Morphis is meant to be customized to fit a customer’s process but if a customer can’t describe their process how can Morphis be customized?
Being new to process mapping they were looking for something that was intuitive and easy to use.
The power of seeing the process laid out visually and the importance of working on the excercise collaboratively.
How Morphis’s implementations are all done virtually over Webex around the globe

Barton George
Sr. Director, Business Development, Blueprint
Lombardi Software

Business Analyst Community & Resources | Modern Analyst

BA ABCs: “B” is for BPMN

Top 10 Tech Skills: Process Modeling tops the list

Morphis: Accidental Process Consultants